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Abstract 

Capstones form an important part of the curriculum in many undergraduate and graduate programs in 
Information Systems. These projects give the students a chance to synthesize and apply the skills 
they have been acquiring throughout their academic program. These projects can be integrated with 
another recent initiative in higher education: service learning. By turning the capstones into "real- 
world" projects for external clients, the students can give back to the community while completing a 
valuable learning experience. However, these real world exercises sometimes take on real world 
characteristics - like failure. How do we, as professors, guide students through a service learning 
capstone to completion, despite the external challenges that come with it? How can we evaluate the 
outcome of these projects, when we know success may not be a part of the final product? The 
authors draw on personal experience with service learning capstones to address this problem. 

Keywords: capstone, service learning, student learning, facilitation 


1. INTRODUCTION 

Capstone projects are popular at both the 
undergraduate and graduate level as a way to 
force students to integrate the information and 
skills they have learned from the various classes 
they have taken in their program (Morgan and 
Aitken, 2006). Some of these capstones take the 
form of classroom projects that can be more 
easily controlled by the instructor (Stillman and 
Peslak, 2009), while others deal with "real 
world" projects for clients outside the classroom 
(Scott, 2006, Reinicke and Janicki, 2010). 

While classroom projects have the advantage of 
being easier to control, there is a recent push for 
service learning at many universities. The 2006 


Model Curriculum for Graduate Degree Programs 
in Information Systems (Gorgone, Gray, Stohr, 
Valacich, & Wigand, 2006) recommends an 
integrated capstone experience. 

Enhanced learning concepts are moving faculty 
to steer more students towards real world 
projects for external clients. These projects can 
be very rewarding for students and faculty. 
However, outside projects face the same 
challenges as those experienced by external 
organizations. This adds an additional level of 
complications to the projects for everyone 
involved, but it also provides some learning 
opportunities for the students. 

Combining the capstone experience with service 
learning can provide an excellent way to both 
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expand the students' knowledge of real world 
issues for systems projects and fulfill the 
universities push for service to the community 
(Lenox, 2008). 

2. PROBLEMS WITH THE REAL WORLD 
COMPONENT 

Combining service learning with a capstone 
experience provides a number of opportunities, 
but it comes with a number of challenges as 
well. The authors draw on experience with 
having worked with students on over 40 
capstone projects for outside clients. The clients 
represented a mix of agencies on campus, area 
non-profits and even some small businesses. 
The problems that can be encountered in real 
world projects are numerous. These are some of 
the most common problems and some solutions 
for them. 

These projects generally take the form of an 
integrated back end database to meet some 
reporting and input needs by the client. In some 
cases the projects need to integrate with 
existing systems. 

The client doesn't know what they want! 

Clients don't always know what they need or 
what they should expect from the system under 
development. While this is certainly frustrating 
for the students, it's also very much a real-world 
problem they will encounter in the work force. 
Clients in the real world will forget requirements, 
lack an understanding of technology and 
occasionally have difficult personalities. 

This can serve as an excellent learning 
opportunity for students. We have frequently 
walked groups through what they can do with 
unclear requirements or what they can do with 
clients to try to crystallize requirements (i.e. 
prototypes, requirements documentation, asking 
for additional details on processes, etc.). While 
this is frustrating for the students, it does force 
them to actually apply the skills they (should) 

have learned in their systems analysis and 

design classes. 

This can also pose problems for the professor 
guiding the project. Clients who are unclear on 
their requirements can reject systems when they 
decide that whatever the students produced 
didn't meet their rather ephemeral 

requirements. If this happens, we generally 

hold the students to their design documents. If 
they built what they said they would, and it 
works, then they have met the requirement for 
the capstone. 


However, a difficulty here is that the client 
perceives that the students did not meet their 
needs (even though they did not define them 
initially), and the reputation and even future 
hiring from the university may be impacted. 

Project creep also occurs. What starts out in the 
mind of the client and the student tends to 
grow. This is very real world, but when you are 
working in a one year or one semester time 
frame, management of this issue is immensely 
important. 

Budget cuts? 

In the real world, projects can be cancelled at 
any point due to a cut in funding. Even when 
the systems are being designed and built for 
free, the agency the students are working for 
can still find themselves short of funds. 
Depending on the timing, this can be very 
disheartening for the students. Especially if it 
happens early in the project, the students can 
lose some of their incentive to work on the 
project. The best approach found here is to tell 
the students that they'll be graded on the 
system they produce, and to point out that if 
they do a good job on it, their system will likely 
be the first thing implemented when the budget 
returns. 

What do you mean you don't need it 
anymore? 

Occasionally, a client will suddenly realize that 
they no longer need the system under 
development. This can happen because of a 
changing business environment, a change in 
priorities for the group or because of another 
initiative within the organization that provides 
duplicate functionality. Regardless, the students 
find out that whatever they develop will not be 
implemented because it's simply no longer of 
interest to the client. 

While this situation can cause despair in the 
student groups, it can also create problems with 
the client. If the client no longer needs the 
system, they have less incentive to work with 
the students, and the students will require a fair 
amount of their time. While the authors have 
not personally experienced this problem with the 
clients (they are generally very happy to work 
with the students and understand that this is a 
learning experience for them), we have certainly 
seen this problem for the students. Generally 
speaking, it's good to tell the students that 
they'll be graded on the system they produce, 
regardless of the client's intention to implement 
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it. Also, we have found that running an in depth 
"post mortem" on the project to find out what 
the students learned can be very helpful. This 
can help them focus on what they learned from 
the project, rather than focusing on the fact that 
their project will likely never see the light of day. 

No one did it before! Where did that come 
from? 

Student projects take time, but they do not 
operate in a vacuum. While they are working on 
their projects, the rest of the world continues to 
generate new systems and business ideas. 
While a given product or service may not have 
been available when the project started, it can 
certainly be there when they are done (or 
before). 

The first author has only had this happen to one 
project, but it did present some interesting 
challenges. The student was working with a 
small business in the area on their idea for a 
new Internet based business, and midway 
through the one year project, another website 
came out that offered everything the business 
had been planning on offering, along with 
additional features. In this case, it was pointed 
out to the student that there are very few 
markets with only a single company in them - 
there is always room for competition. The 
student continued to work on the project, and 
while the small business ultimately decided not 
to pursue the opportunity; it was an excellent 
learning opportunity for the student. 

I can't work with this person. 

Group dynamics are problematic for every 
student group, which is also reflective of the real 
world. The students have to learn how to deal 
with difficult people, and this is generally 
something that is not covered in the curriculum. 
Thus, these projects can serve as a learning 
opportunity for this skill set. 

If the problem is with another student in a 
group, there are a variety of ways to deal with 
it. One of the most common complaints in 
students groups is slacking, but this is 
something that can be dealt with in the structure 
of the projects. One solution for this problem is 
to have the students grade one another on the 
level of effort that they put into the project. 
This should constitute enough of the grade to 
have the students' attention, which provides the 
instructor with a way to lower the grade for 
those students who are slacking. 


If this conflict is with the client, it poses a larger 
problem. Again, this is something that the 
students will have to deal with in the business 
world, so giving the student guidance here can 
be helpful. Some ways to deal with this are to 
encourage the student to find out which way is 
easiest to deal with the client (phone, e-mail or 
in person meetings) to try to reduce the friction 
and to find ways to get the information required 
with minimal contact. Depending on how bad 
the situation is, it may be necessary for the 
faculty member to mediate between the groups, 
but this should not be the first solution. After 
all, the students' future boss won't be happy 
about the fact that they have to mediate 
between their newest employee and their 
clients. 

The client changed their mind...again! 

Just as with any real world project, clients can 
be fickle. It's not unusual for the client to shift 
the scope for the project slightly (or greatly) as 
the students are working on it. While nothing 
can prevent the client from changing their mind 
early in the project, you can take steps to 
minimize the impact on the student teams later 
on. Specifically, having the students create a 
project charter or work agreement for the client 
(an excellent application of something they 
should have picked up in Systems Analysis and 
Design) and having the client sign it is a good 
way to prevent this from becoming an issue. 

A word of caution based on experience. It's 
important to review the document before the 
students take the document to the client. There 
seems to be a tendency for the students to 
assume a great deal with the documents, rather 
than taking the time to spell out specifics. 
However, a vague project charter has doomed 
more than one real world project! The first 
author has found that going through a draft or 
two of the document before submitting it to the 
client to be beneficial, because you can force the 
students to go to a certain level of detail. The 
students are then required to keep a copy 
signed by the client and emphasize to them that 
this is their contract with the client for the work 
they need to perform (and will therefore be 
graded on). 

The client wants me to solve world hunger. 

With any real world project, the vision for the 
system can easily outstrip the available 
resources, and these types of projects are no 
exception. It's important to set realistic 
expectations with the client when you, the 
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professor, are first discussing the project with 
them. It's also important to prevent "scope 
creep" from setting in once the students are on 
the project. Again, one of the most effective 
ways of avoiding this problem is to create scope 
documents for the project that are reviewed with 
the client, and then signed by the client and the 
students. So long as that documentation is 
there, and everyone has reviewed it, this 
problem can be minimized. 

However, it has been our experience that some 
clients will push the students to add features, 
regardless of the documentation. Again, this is 
certainly something that they will see in the real 
world. In these cases, the instructor can remind 
the students that they will be graded on whether 
or not their final product fulfills the original 
scope of the project. If there is time at the end, 
they can add in the additional features, but in 
the meantime tell the client that your first 
priority is to meet the requirements laid out in 
the scope document. If the client continues to 
push, it may be necessary for the professor to 
talk to them directly about what is realistic for a 
student project. 

We have found at times, that clients forget that 
these are student teams, and not 'for pay' 
consultants. 

Time Allocation and Learning Curve of the 
Students. 

In our situation the students receive only 6 
credits over two semesters for the capstone 
project. For some of the projects this just isn't 
enough time for the students to learn new 
concepts of interviewing, design documents, 
story boarding, database design and 
implementation and a final production schedule. 

This leaves the issue of what happens with 75% 
completed projects? Do we let the client 
hanging? The student has graduated! 

We manage some of the client expectation by 
informing them that if the project is not 
completed by the agreed upon time, the next 
semester a high power team of students will 
complete the project. 

How long did it take? 

This is less an issue for the students than the 
professor. A common requirement for service 
learning initiatives is that the time the students 
spend on the project be tracked and reported to 
the university. A simple solution for this is to 


require the students, as part of the project, to 
submit time sheets. 

This can be done either weekly or at the 
completion of the project. It has been our 
observation that the students are more accurate 
and attuned to this requirement if they have a 
weekly deliverable to turn in. We have also 
found it's best not to grade them on the number 
of hours spent; this leads to a rather predictable 
inflation of the hours spent on the project. 
Rather, we grade them on turning in a 
completed time sheet for the group every week 
and simply make it a small part of their overall 
grade. 

Who will maintain the system? 

At the end of the project, one of the questions 
that must be asked is who will maintain the 
completed system. This is less a burden for the 
students than for the professors who are running 
the class. Generally speaking, this requires 
some coordination between the faculty and the 
clients to transition the system to the clients. 
For our class, following a final presentation by 
the students at the end of the semester, the 
faculty member will work with the client to move 
the files to a server maintained by the client. 
Following this, it is the client's responsibility to 
put the system into production and maintain it. 
The department has a connection with a hosting 
service that works with nonprofit agencies if 
they need help with setting up and maintaining 
the system. 

We have worked with the same clients 
repeatedly, where new student projects are 
enhancements to or extensions of existing 
systems completed by students in earlier 
semesters. 

3. CONCLUSIONS 

The twin demands of service learning and 
capstone projects can be combined beneficially, 
but there are additional challenges associated 
with combining these efforts. While combining 
these places additional demands on the students 
and the faculty responsible for the projects, this 
combination can provide valuable learning 
experiences for the students and can expand the 
university's presence in the community. 
However failure to manage both the client 
expectations and student progress may actually 
hurt the reputation of the university in the 
community. 
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